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REMARKS 



In reply to the Office Action mailed June 16, 2003, and in view of the following remarks, 
reconsideration is requested. Claims 5 and 19-48 remain in the application of which claims 5, 24, 
30, 36, 42 and 43 are independent. 

Information Disclosure Statement of July 23. 2002 
The Applicant notes that a PTO-1449 form submitted with the information disclosure 
statement filed July 23, 2002 was not signed and returned by the Examiner. Acknowledgement 
and consideration of that information disclosure statement is respectfully requested. 

Rejection under 35 U.S.C. 103 
Claims 5, 7, 8, 17 and 18 were rejected under 35 U.S.C. §103 in view of U.S. Patent 
5,799,150 (Hamilton) and U.S. Patent 5,920,572 (Washington). 



According to Hamilton, a distributed multimedia computing system (Fig. 1) includes 
client computers 50 and a server computer 40 (Fig. 2). The server computer 40 includes "a 
processor 54 and system memories 56 which are interconnected with [a] disk 52 via a bus 58. 
This bus 58 is also connected to a network interface 60 which connects to the media transport 
42." Hamilton, Col. 4, lines 64-67. The client computer 50 includes a "processor 62 and main 
memory 64 interconnected by a bus 66. Also connected to the bus are preferably video memory 
63 and audio memory 65 . . .. This bus [58] connects to a network interface 68 which connects 
to a network interface 68 which connects the client 60 to the media transport 42, and thus to 
server 40." Hamilton, Col. 5, lines 1-4, 6-8. "The media transport 42 and network interface 60 
is provided by an optical fiber with the FORE Systems ForeRunner VMA-200 ATM VMEbus 
Adapter for the server 40 . . .." Hamilton, Col. 5, lines 15-18. 

Regarding the communication between the client and the server, Hamilton states, at Col. 
9, lines 14-37, 48-67, and Col. 10, lines 1-8: 

"The network interface (FIG. 7) is used in the following manner to control flow 
between the sender or server 40 and client 50. First, ... for each track in a 

multimedia program, a virtual receive channel is created For each virtual 

receive channel at the client a logical DMA is created in the network interface 68. 
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When the client places a request to the server for media data, an identifier of the 
receive channel to which media data will be sent is included, along with an 
indication of the media file to be accessed and an amount of data requested from 
it, called a transfer unit, is also provided. . . . Next, at the transport level, a 
window packet is sent in step 92, authorizing one transfer unit to be sent to this 
receive channel. However, the virtual receive channel only has a given size S, i.e., 
a maximum amount of data that it may hold. The ability of the network interface ' 
to buffer data is also limited. Thus, the window packet authorizing a transfer unit 
only authorizes a number of bytes to be sent which is less than the size S of the 
virtual channel. . . . 

The network interface prepares media data to be sent by reading network packet 
size data chunks from the addresses specified for the appropriate transmit channel, 
with the last chunk being of arbitrary length, while encapsulating the data in 
proper header information then sending completed packets to the destination 
node. The network interface only reads as many bytes as specified. The data 
packet sent also includes the identifier of the receive channel previously provided 
by the client. 

The received data is then processed by the client in step 94. For reception, the 
data must be separated from the packet and moved to buffers for use. 
Traditionally this separation is performed by the client after the packet has been 
moved into system memory by the network interface. The client then moves the 
data to the appropriate destination using a software copy loop. However, no 
. system memory buffer copy is possible given the data rates required of broadcast 
quality video. This traditional method is bypassed in this invention to enhance 
throughput by minimizing data copying using direct memory access (DMA). The 
identifier of the receive channel is used along with the state variables of the 
receive data channel by the network interface under DMA control to transfer the 
media data portion of the packet directly from the memory 80 network interface 
into the main memory or other i/o device memory, such as video memory 63 or 
audio memory 65, thus enhancing throughput, as shown in FIG. 7. After the 
received data is processed, a window authorization is sent again for more data in 
step 92." 

The Office Action asserts that it is notoriously well known that "within a basic DMA 
packet format there exist a Stream ID." Office Action, page 3, lines 7-10. This discussion of 
DMA packets (in contrast to packets in a network communication protocol in Hamilton) is 
irrelevant in view of the fact that in Hamilton, «'[w]hen the client places a request to the server 
for media data, an identifier of the receive channel to which media data will be sent is included," 
and *'[t]he data packet sent also includes the identifier of the receive channel previously provided 
by the client." Hamilton, Col. 9, lines 23-25 and 54-56. 
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According to Washington, a system decodes and demultiplexes video and audio data 

streams from a hierarchically organized transport stream, such as an MPEG-2 compliant 

transport stream. See Washington, Col 1, lines 8-14. Washington states that a: 

"transport stream is a stream of bits formed from consecutive transport packets .... In 
order to recover the information in the transport packets, the packet framer 120 must 
determine where each packet begins and ends (i.e., the boundaries of each packet). 
However, the transport stream . . . need not begin on a transport packet boundary. 
Illustratively, the packet framer locks onto the boundaries of the transport packets and 

maintains the synchronization with the transport packets [A]ll transport packets 

begin with a predetermined sync byte. " 

Washington, Col 10, lines 53-65. How the sync bytes are used to locate transport packets is 
described from Col. 10, line 65 to Col. 1 1, line 20. Thus, Washington teaches that a "sync byte" 
is at the beginning of each transport packet, and that this sync byte enables some processor, such 
as the packet framer 120 to "determine where each packet begins and ends." Id. 

The Office Action asserts that this portion of Washington, i.e., the use of a sync byte in 
each packet to enable a determination that begins a transport packet in an MPEG-2 compliant 
data stream, is a teaching of "a boundary signal portion including a boundary signal indicating 
that the data packet tends with the last component of the read data." Office Action, page 3, last 
two lines. To the extent that the Office Action is asserting that the claim language reads on this 
portion of Washington, that issue is addressed in more detail below. Irrespective of the claim 
language in this application, Washington does not teach that these sync bytes (that appear in 
every packet) indicate in any way that any particular packet includes the last component of data 
being read, i.e., the last component of data being transmitted using a set of packets. The sync 
bytes in Washington are merely used (by the packet framer) to determine where each packet 
begins and ends in the data stream. Because every packet has a sync byte, the sync byte 
therefore is independent of the data content of any packet. 

Considering the collective teachings of Hamilton and Washington, the Office Action 
asserts that it would have been obvious to modify Hamilton "by including a boundary signal to 
indicate that the data packet ends with the last component of the read data (boundaries of each 
packet), as taught by Washington, so Hamilton's system able [sicl to detect the syncrhonization 
status of the transport packets with the transport stream by identifying the boundaries of each 
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packet ... Office Action, page 4, lines 2-7. In essence, it appears that the Office Action is 
asserting that each packet in Hamilton would have been modified to have a "sync byte" as 
disclosed in Washington so as to enable the boundaries of each of Hamilton's packets to be 
detected. However, in Washington, the position of each transport packet in a transport stream 
might not be known a priori. That is because "the transport stream . . . need not begin on a 
transport packet boundary." Washington, Col. 10, lines 58-60. In Hamilton, each packet is a 
packet in a known communication protocol on a packet switched network, and the boundaries of 
each packet are presumed to be known a priori. Therefore, the reason for using a sync byte in 
Washington is not present in Hamilton. Therefore, one of ordinary skill in the art would not 
have found it obvious to modify Hamilton with the teachings of Washington. Accordingly, the 
rejection of claims (namely, claim 5, now amended not to include the limitation, but see new 
claim 42) reciting such a "boundary signal" is traversed, and any new claims presented in this 
Reply including such a limitation are patentable over Hamilton and Washington, as discussed in 
more detail below. 

The Office Action also considers the collective teachings of Hamilton, Washington and 
the IEEE-1394 standard, The Office Action takes Official Notice "that the use of IEEE-1394 
communication media for data communication between two devices is notoriously well known 
. ." A standard is defined for transporting audio and video data over an IEEE-1394 compliant 
bus, and is called IEC-61883 Hamilton teaches a protocol for transmitting audio and video 
between multiple clients and a server over a packet switched network. Because the Office 
Action relies on the teachings of Hamilton's protocol as the basis for the rejection, the Applicant 
assumes that the Office Action is proposing a modification to Hamilton that merely replaces the 
packet switch network with an IEEE-1394 serial bus, but without using the an existing standard 
for transmitting audio and video data over an ffiEE-1394 bus. However, there is no evidence 
relied upon in the Office Action to suggest that one of ordinary skill in the art would have been 
motivated to make such a modification or that such a modification would have been considered 
desirable. Therefore, the rejections (of claims 17 and 18, now cancelled) relying on the IEEE- 
1394 standard are traversed. Further, for the same reasons, the amended and new claims 
presented in this Reply (namely, all of the independent claims) that recite a "high speed serial 
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bus" are patentable over Hamilton, Washington and IEEE-1394, as discussed in more detail 
below. 

Comparison of Claims to Hamilton and Washington and IEEE-1394 

Having now addressed what Hamilton, Washington and IEEE-1394 teach, the claims will 
now be compared to those teachings. Independent claim 5 has been amended and the remaining 
dependent claims were cancelled. Several claims have been added. Accordingly, these Remarks 
address claim 5 as amended and the additional claims. The other independent claims (newly 
added claims 24, 30 and 36) have limitations similar to claim 5 and are allowable for at least the 
same reasons that are set forth below. 

Claim 5 has been amended to recite "transferring data . . . over a high speed serial bus . . . 
using frame by frame flow control." Support for this limitation is found at page 18, line 17 of 
the present application. In such flow control, as recited in amended claim 4, "each request 
packet indicates a request ... to transfer a frame of video data." Further, "in response to a 
request packet, a plurality of data packets [is sent] including video data for the requested frame." 
These clauses also indicate that a plurality of data packets is used to send the video data of a 
requested frame. Hamilton, as noted above, involves requests for any amount of data depending 
on the available buffer size. Thus, Hamilton does not teach such "frame by frame flow control." 

The Applicant also notes that claim 5 recites that the transfer occurs over a high-speed 
serial bus. It is noted above that Hamilton would not have been modified by one of ordinary 
skill in the art so as to use IEEE-1394 as the media transport between the server and client. 

For these reasons, independent claim 5 and the other independent claims (24, 30 and 36) 
are patentable over Hamilton, Washington and IEEE-1394. 

Each of the dependent claims 22, 28, 34 and 40 recites a "boundary signal indicating 
whether the data packet includes a last component of the video data of the requested frame," 
which is similar to language found in claim 5 prior to this Reply. This language does not read on 
Washington's use of "sync bytes." The plain language of the claim makes it clear that the 
boundary signal in a data packet indicates whether that data packet includes the last component 
of the requested frame. The term "component" is defined at page 7, lines 9-10 of the present 
application: "A component is a portion of the data being transferred, such as a luminance 
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component of a pixel of video data." In Washington, whether a transport packet includes the last 
component of any frame of video cannot be determined from the mere "sync byte" because every 
sync byte in every transport packet is the same. The sole purpose of the sync byte in a packet is 
to identify boundaries (start and end) of the packet in a data stream; the sync byte does not 
identify anything about the data being transferred in the packet. Accordingly, claims 22, 28, 24 
and 40 are patentable over Hamilton and Washington. 

Newly added dependent claims also recite limitations that are taught neither by Hamilton 
nor by Washington, including: 

a. "data representing a component of the video data has a precision greater than a byte 
and wherein the data representing the component of the video data is packed into bytes in the 
plurality of data packets," as recited in claim 19, and "the plurality of data packets includes a 
component size field indicating a number of bits per component," as recited in claim 20. Similar 
limitations are found in claims 25, 26, 31, 32, 37 and 38. Support for these limitations is found 
at page 7, lines 5-16 of the present application. 

b. "at least one of the data packets . . . includes a target field indicating a device to which 
the video processing device is directed to transfer the video data," as recited in claim 21. Similar 
limitations are found in claims 27, 33 and 39. Support for these limitations is found at page 6, 
lines 10-30 of the present applications. 

c. "the host device further sends, through the output, a data packet including a command 
field indicating a command to the video processing device," as recited in claim 23. Similar 
limitations are found in claims 29, 35 and 41. Support for these limitations is found at page 9, 
lines 26-32 of the present application. 

Accordingly, these dependent claims also are allowable over Hamilton and Washington. 

Regarding independent claim 42, this claim recites that "each data packet includes the 
stream identifier and a boundary signal indicating whether the data packet ends with a last 
component of the requested frame." As noted above, this language does not read on any 
purported combination of Hamilton and Washington. 
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Regarding independent claim 43, this claim recites a "high speed serial bus" and that the 
host device sends data packets "at a packet rate set by the sender according to the received 
request packet." A request packet "indicates that the video processing device is capable of 
receiving data." Support for these limitations is found on page 9, lines 10-20 of this application. 
As noted above, these claims are distinguishing over Hamilton, Washington and IEEE-1394 
because a. the modification of Hamilton using IEEE-1394 is not supported by the evidence relied 
on in the Office Action, and b. neither Hamilton, nor Washington nor IEEE-1394 teach the 
setting of the packet rate as recited in claim 43. Additional limitations regarding the packet rate 
are found in dependent claim 44. Dependent claims 45-48 are similar to claims 37 and 38 and 
are allowable for at least the same reasons. 



In view of the foregoing amendments and remarks, this application should now be in 
condition for allowance. A notice to this effect is respectfully requested. If the Examiner 
believes, after this reply, that the application is not in condition for allowance, the Examiner is 
requested to call the Applicants' attorney at the telephone number listed below. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicants hereby request any necessary extension of time. If there is a fee 
occasioned by this response, including an extension fee, please charge any fee to Deposit 
Account No. 50-0876. 



CONCLUSION 



RECEIVED 

CENTRAL FAX CENTER 

SEP 1 7 2003 



Avid Technology, Inc. 
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Avid Technology Park 
Tewksbury, Massachusetts 01876 



Tel. No.: 978.640.6789 
Attorney for Applicant 



Date: September 16, 2003 
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